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Abstract 

We prove that a particular pushing-blocks puzzle is intractable in 3D. 
The puzzle, inspired by the game PushPush, consists of unit square blocks 
on an integer lattice. An agent may push blocks (but never pull them) 
in attempting to move between given start and goal positions. In the 
PushPush version, the agent can only push one block at a time, and 
moreover, each block, when pushed, slides the maximal extent of its free 
range. We prove this version is NP-hard in 3D by reduction from SAT. 
The corresponding problem in 2D remains open. 



1 Introduction 

There are a variety of "sliding blocks" puzzles whose time complexity has been 
analyzed. One class, typified by the 15-puzzle so heavily studied in AI, permits 
an outside agent to move the blocks. Another class falls more under the guise of 
motion planning. Here a robot or internal agent plans a path in the presence of 



movable obstacles. This line was initiated by a paper of Wilfong [Wil91|, who 
proved NP-hardness of a particular version in which the robot could pull as well 
as push the obstacles, which were not restricted to be squares. Subsequent work 
sharpened the class of problems by weakening the robot to only push, never pull 
obstacles, a nd by r estricting all obstacles to be unit squares. Even this version 



is NP-hard |D092 | 



One theme in this research has been to establish stronger degrees of in- 
tractability, in particular, to distinguish between NP-hardness and PSPACE- 
complcteness, the latter being the stronger claim. The NP-hardness proved 



in | D092| was strengthened to PSPACE-completeness in a unfinished manu- 



script |BOS94|. More firm are the results on Sokoban, a computer game that 



restricts the pushing robot to only push one block at a time, and requires the 
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storing of (some or all) blocks into designated "storage locations." This game 



was proved NP-hard in pZ95( |, and PSPACE-complete by Culberson |Cul98 |. 

Here we emphasize another theme: finding a nontrivial version of the game 
that is not intractable. To date only the most uninteresting versions are known 
to be solvable in polynomial time, for example, where the robot's path must 



be monotonic [D092]. We explore a different version, again inspired by a com- 
puter game, PushPush. The key difference is that when a block is pushed, it 
necessarily slides the full extent of the available empty space in the direction in 
which it was shoved. This further weakens the robot's control, and the resulting 
puzzle has certain polynomial characteristics. We prove it is intractable in 3D, 
but leave the question of whether it is polynomial in 2D an open problem. 



2 Problem Classification 

The variety of pushing- block puzzles may be classified by several characteristics: 

1. Can the robot pull as well as push? 

2. Are all blocks unit squares, or may they have different shapes? 

3. Are all blocks movable, or are some fixed to the board? 

4. Can the robot push more than one block at a time? 

5. Is the goal for the robot to move from s to t, or is the goal for the robot 
to push blocks into storage locations? 

6. Do blocks move the minimal amount, exactly how far they are pushed, or 
do they slide the maximal amount of their free range? 

7. The dimension of the puzzle: 2D or 3D? 

If our goal is to find the weakest robot and most unconstrained puzzle condi- 
tions that still lead to intractability, it is reasonable consider robots who can only 



push (1), and to restrict all blocks to be unit squares (2), as in |D092, DZ95 



Cul9^ , for permitting robots to pull, and permitting blocks of other shapes. 



makes it relatively easy to construct intractable puzzles. It also makes sense to 



explore the goal of simply finding a path (5) as in [ Wil91 , D092|, r a ther th an 
the more challenging task of storing the blocks as in Sokoban DZ95 , Cul98 |. 

Restricting attention to these choices still leaves a variety of possible problem 
definitions. If the robot can only move one block at a time, then the distinction 
between all blocks movable and some fixed disappears, because 2x2 clusters of 
blocks are effectively fixed to a robot who can only push one. If all blocks are 
movable and the robot can push more than one at a time, then the blocks should 
be confined to a rectangular frame. 

The version explored in this paper superficially seems that it might lend 
itself to a polynomial-time algorithm: the robot can only push one block (4), 
all blocks are pushable (3), and finally, the robot's control over the pushing 
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is further weakened by condition (6): once pushed, a block shdes (as without 
friction) the maximal extent of its free range in that direction. We show the 
problem is intractable in 3D, and discuss the 2D version in the final section. 

3 Elementary Gadgets 

First we observe, as mentioned above, that any 2x2 cluster of movable blocks 
is forever frozen to a PushPush robot, for there is no way to chip away at this 
unit. This makes it easy to construct "corridors" surrounded by fixed regions 
to guide the robot's activities. We will only use corridors of width 1 unit, with 
orthogonal junctions of degree two, three, or four. We can then view a particular 
PushPush puzzle as an orthogonal graph, whose edges represent the corridors, 
understood to be surrounded by sufficiently many 2x2 clusters to render any 
movement outside the graph impossible. We will represent movable blocks in 
the corridors or at corridor junctions as circles. 
We start with three elementary gadgets. 

3.1 One- Way Gadget 

A "one-way" gadget is shown in Fig. |^a. It has these obvious properties: 

X 

^ v ^ 

(a) (b) (c) 

Figure 1: One- Way gadget: permits passage from a; to y but not from y to a;. 

Lemma 1 In a One-Way gadget, the robot may travel from point x to point 
y, but not from y to x. (After travelling from x to y, however, the robot may 
subsequently return from y to x.) 

Proof: The block at the degree-three junction may be pushed into the storage 
corridor when approaching from x, as illustrated in Fig. |l|b, but the block may 
not be budged when approaching from y (Fig. ||c). □ 

3.2 Fork Gadget 

The fork gadget shown in Fig. ||a presents the robot with a binary choice, the 
proverbial fork in the road: 
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(a) (b) (c) 

Figure 2: Fork gadget: Robot may pass (b) from x to y or (c) from x to z, but 
each seals off the other possibihty. 

Lemma 2 In a Fork gadget, the robot may travel from point x to y, or from 
X to z, but if it chooses the former it cannot later move from y to z, and if it 
chooses the latter it cannot later move from z to y. (In either case, the robot 
may reverse its original path.) 

Proof: Fig. |^ shows the only way for the robot to pass from x to y. Now 
the corridor to z is permanently sealed off. Fig. |^c shows the only way to move 
from x to z. Here any attempt later to access the corridor leading to y will 
necessarily push block B to corner w, sealing off y. □ 
Note that in both these gadgets, the robot may reverse its path, a point to 
which we will return in Section ^. 

3.3 3D Crossover Gadget 

Crossovers are trivial in 3D, as shown in Fig. 0. 
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Figure 3: 3D crossover. The central small circle is a wire orthogonal to the 
plane of the figure. 



4 Variable-Setting Component 

The robot first travels through a series of variable-setting components, each of 
which follows the structure shown in Fig. ^: a Fork gadget, followed by two 
paths, labeled T and F, each with attached wires exiting to the right, followed 
by a re-merging of the the T and F paths via One- Way gadgets. 3D crossovers 
are illustrated in this and subsequent figures by broken-wire underpasses. 



iv 




Figure 4: (a) Variable Xi component. 



Lemma 3 The robot may travel from a to b only by choosing either the T-path, 
or the F-path, but not both. Whichever T/p-path is chosen allows the robot to 
travel down any wires attached to that path, but down none of the wires attached 
to the other path. 

Proof: The claims follow directly from Lemma || and Lemma ^ □ 

5 Clause Component 

The clause component shown in Fig. cannot be traversed unless one or more 
blocks are pushed in from the left along the attached horizontal wires. 
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Figure 5: (a) Clause Cj component. 
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Lemma 4 The robot may only pass from x to y of a clause component if at 
least one block is pushed into it along an attached wire (a, b, or c in Fig. ^a). 
Proof: Block A is necessarily pushed by the robot starting at x. This block 
will clog exit at y (Fig. |^) unless its sliding is stopped by a block pushed in on 
an attached wire. □ 



6 Complete SAT Reduction 

The complete construction for four clauses Ci A C2 A C3 A C4 is shown in Fig. ^. 
Two versions of the clauses are shown in the figure: an unsatisfiable formula 
(the dark lines), and a satisfiable formula (including the shaded X2 wire): 



(xi V X2) A (a;iV X2) xiV X3) A (~ xiV ~ X3) (1) 
{xi V X2) A (a;iV ^ X2) A ('-- a;i V X2 V X3) A xiW ^ x^) (2) 

Here we are using ~ a; to represent the negation of the variable x. 
A path from s to t in the satisfiable version is illustrated in Fig. ^. 

Theorem 1 PushPush is NP-hard in 3D. 

Proof: The construction clearly ensures, via Lemmas ||andQ that if the simu- 
lated Boolean expression is satisfiable, there is a path from s to t, as illustrated 
in Fig. 1^. For the other direction, suppose the expression is unsatisfiable. Then 
the robot can reach t only by somehow "shortcutting" the design. The design 
of the variable components ensures that only one of the t/f paths may be ac- 
cessed. The crossovers ensure there is no "leakage" between wires. The only 
possible thwarting of the design would occur if the robot could travel from a 
clause component back to set a variable to the opposite Boolean value. But 
each variable-clause wire contains a block that prevents any such leakage. □ 



7 PushPush in 2D 



It is an intriguing question whether the 2D version of this problem is intractable. 
One result in this direction is easy to obtain: 

Theorem 2 The storage version of PushPush is NP-hard in 2D. 
Proof: In the storage version of PushPush,[] the robot must fill certain storage 
locations with blocks, as in Sokoban. It is then easy to obtain an NP-hardness 
proof along the lines of the NP-hardness proof of Dor and Zwick |DZ95|. Rather 
than reducing from SAT, reduce from "Planar 3-SAT" |Lic82]. This, together 
with the storage requirement, removes the need for any crossovers. The con- 
struction can then follow the design as in Fig. ^. Details are similar to those 
in |DZ95| and will not be presented. □ 



This, incidentally, is the actual design of the computer game. 
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Figure 6: Complete construction for the formulas in Eq. (1) and Eq. (2) (in- 
cluding the shaded portion). 
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Figure 7: Solution path for Eq. (2). 
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The reason that Planar 3-SAT does not help for the path version of PushPush 
is that crossovers are still needed to thread the clause components together into 
a single path. And it seems that the PushPush conditions are too weak to 
construct the required crossover gadget: 

Conjecture 1 No general crossover gadget can he constructed in 2D PushPush. 

Such a gadget would permit two wires to cross, but would prevent leakage from 
one to the other, just as if it were a 3D crossover. One reason this seems 
impossible is this: 

Conjecture 2 No permanent one-way gadget can he constructed in 2D Push- 
Push. 

Note that the the properties of the One- Way gadget in Fig. |^ are destroyed by 
passage of the robot, after which it becomes a two-way street. 

We conclude by summarizing in Table ^ previous work according to the 
classification scheme offered in Section ^ The first four lines show previous 
results. The next two are the results from this paper. And the last two lines 



pose two open problems, one raised here, the other in | D092| : Is PushPush (path 
version) intractable in 2D? And is the problem where all blocks are movable and 
the robot can push k blocks, sliding the minimal amount, intractable in 2D? 
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Table 1: Pushing block problems. 
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